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Expect-CT Extension for HTTP 


Abstract 


This document defines a new HTTP header field named "Expect-CT", which allows web host 
operators to instruct user agents (UAs) to expect valid Signed Certificate Timestamps (SCTs) to be 
served on connections to these hosts. Expect-CT allows web host operators to discover 
misconfigurations in their Certificate Transparency (CT) deployments. Further, web host 
operators can use Expect-CT to ensure that if a UA that supports Expect-CT accepts a misissued 
certificate, that certificate will be discoverable in Certificate Transparency logs. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for examination, 
experimental implementation, and evaluation. 


This document defines an Experimental Protocol for the Internet community. This document is a 
product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF 
community. It has received public review and has been approved for publication by the Internet 
Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for 
any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9163. 


Copyright Notice 


Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
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with respect to this document. Code Components extracted from this document must include 
Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 
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1. Introduction 


This document defines a new HTTP header field ({[RFC9110], Section 6.3) that enables UAs to 
identify web hosts that expect the presence of Signed Certificate Timestamps (SCTs) [RFC9162] in 
subsequent Transport Layer Security (TLS) [RFC8446] connections. 


Web hosts that serve the Expect-CT header field are noted by the UA as "Known Expect-CT Hosts". 
The UA evaluates each connection to a Known Expect-CT Host for compliance with the UA's 
Certificate Transparency (CT) Policy. If the connection violates the CT Policy, the UA sends a 
report to a URI configured by the Expect-CT Host and/or fails the connection, depending on the 
configuration that the Expect-CT Host has chosen. 


If misconfigured, Expect-CT can cause unwanted connection failures (for example, if a host 
deploys Expect-CT but then switches to a legitimate certificate that is not logged in Certificate 
Transparency logs or if a web host operator believes their certificate to conform to all UAs' CT 
policies but is mistaken). Web host operators are advised to deploy Expect-CT with precautions by 
using the reporting feature and gradually increasing the time interval during which the UA 
regards the host as a Known Expect-CT Host. These precautions can help web host operators gain 
confidence that their Expect-CT deployment is not causing unwanted connection failures. 


Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks 
the information necessary to require SCTs for the connection. Thus, the UA will not be able to 
detect and thwart an attack on the UA's first connection to the host. Still, Expect-CT provides 
value by 1) allowing UAs to detect the use of unlogged certificates after the initial communication, 
and 2) allowing web hosts to be confident that UAs are only trusting publicly auditable 
certificates. 
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Expect-CT is similar to HTTP Strict Transport Security (HSTS) [RFC6797] and HTTP Public Key 
Pinning (HPKP) [RFC7469]. HSTS allows websites to declare themselves accessible only via secure 
connections, and HPKP allows websites to declare their cryptographic identifies. Similarly, 
Expect-CT allows websites to declare themselves accessible only via connections that are 
compliant with CT Policy. 


This Expect-CT specification is compatible with [RFC6962] and [RFC9162], but not necessarily with 
future versions of Certificate Transparency. UAs will ignore Expect-CT header fields from web 
hosts that use future versions of Certificate Transparency, unless a future version of this 
document specifies how they should be processed. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


1.2. Terminology 


Terminology is defined in this section. 


"Certificate Transparency Policy" 
A policy defined by the UA concerning the number, sources, and delivery mechanisms of 
Signed Certificate Timestamps that are associated with TLS connections. The policy defines the 
properties of a connection that must be met in order for the UA to consider it CT qualified. 


"Certificate Transparency Qualified" 
Describes a TLS connection for which the UA has determined that a sufficient quantity and 
quality of Signed Certificate Timestamps have been provided. 


"CT Qualified" 
An abbreviation for "Certificate Transparency Qualified". 


"CT Policy" 
An abbreviation for "Certificate Transparency Policy". 


"Effective Expect-CT Date" 
The time at which a UA observed a valid Expect-CT header field for a given host. 


"Expect-CT Host" 
Aconformant host implementing the HTTP server aspects of Expect-CT. This means that an 
Expect-CT Host returns the Expect-CT response header field in its HTTP response messages 
sent over secure transport. The term "host" is equivalent to "server" in this specification. 


"Known Expect-CT Host" 
An Expect-CT Host that the UA has noted as such. See Section 2.3.2.1 for particulars. 
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"User Agent (UA)" 
For the purposes of this specification, a UAis an HTTP client application typically actively 
manipulated by a user [RFC9110]. 


"Unknown Expect-CT Host" 
An Expect-CT Host that the UA has not noted. 


2. Server and Client Behavior 


2.1. Response Header Field Syntax 


The Expect-CT response header field is a new field defined in this specification. It is used by a 
server to indicate that UAs should evaluate connections to the host emitting the header field for 
CT compliance (Section 2.4). 


Figure 1 describes the syntax (Augmented Backus-Naur Form) of the header field, using the 
grammar defined in [RFC5234] and the rules defined in Section 5 of [RFC9110]. The "#" ABNF 
extension is specified in Section 5.6.1 of [RFC9110]. 


Expect-CT 
expect-ct-directive 
directive-name 
directive-value 


1#expect-ct-directive 

directive-name [ "=" directive-value ] 
token 

token / quoted-string 


Figure 1: Syntax of the Expect-CT Header Field 


The directives defined in this specification are described below. The overall requirements for 
directives are: 


1. The order of appearance of directives is not significant. 


2. A given directive MUST NOT appear more than once in a given header field. Directives are 
either optional or required, as stipulated in their definitions. 


3. Directive names are case insensitive. 

4. UAs MUST ignore any header fields containing directives, or other header field value data that 
does not conform to the syntax defined in this specification. In particular, VAs MUST NOT 
attempt to fix malformed header fields. 

5. If a header field contains any directive(s) the UA does not recognize, the UA MUST ignore 
those directives. 

6. If the Expect-CT header field otherwise satisfies the above requirements (1 through 5), and 
Expect-CT is not disabled for local policy reasons (as discussed in Section 2.4.1), the UA MUST 
process the directives it recognizes. 


2.1.1. The report-uri Directive 


The OPTIONAL report-uri directive indicates the URI to which the UA SHOULD report Expect-CT 
failures (Section 2.4). The UA POSTs the reports to the given URI as described in Section 3. 
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The report-uri directive is REQUIRED to have a directive value, for which the syntax is defined 
in Figure 2. 


report-uri-value = (DQUOTE absolute-URI DQUOTE) / absolute-URI 


Figure 2: Syntax of the report-uri Directive Value 
The 'report-uri-value’ MUST be quoted if it contains any character not allowed in 'token’. 
absolute-URT is defined in Section 4.3 of [RFC3986]. 


UAs MUST ignore any report-uri that does not use the HTTPS scheme. UAs MUST check Expect- 
CT compliance when the host in the report-uri is a Known Expect-CT Host; similarly, UAs MUST 
apply HSTS [RFC6797] if the host in the report-uri is a Known HSTS Host. 


UAs SHOULD make their best effort to report Expect-CT failures to the report-uri, but they may 
fail to report in exceptional conditions. For example, if connecting to the report-uri itself 
incurs an Expect-CT failure or other certificate validation failure, the UA MUST cancel the 
connection. Similarly, if Expect-CT Host A sets a report-uri referring to Expect-CT Host B, and if 
B sets a report-uri referring to A, and if both hosts fail to comply to the UA's CT Policy, the UA 
SHOULD detect and break the loop by failing to send reports to and about those hosts. 


Note that the report-uri need not necessarily be in the same Internet domain or web origin as 
the host being reported about. Hosts are in fact encouraged to use a separate host as the report- 
uri so that CT failures on the Expect-CT Host do not prevent reports from being sent. 


UAs SHOULD limit the rate at which they send reports. For example, it is unnecessary to send the 
same report to the same report-uri more than once in the same web-browsing session. 


2.1.2. The enforce Directive 


The OPTIONAL enforce directive is a valueless directive that, if present (i.e., it is "asserted"), 
signals to the UA that compliance to the CT Policy should be enforced (rather than report-only) 
and that the UA should refuse future connections that violate its CT Policy. When both the 
enforce directive and report-uri directive (as defined in Figure 2) are present, the 
configuration is referred to as an "enforce-and-report" configuration, signaling to the UA that 
both compliance to the CT Policy should be enforced and violations should be reported. 


2.1.3. The max-age Directive 


The max-age directive specifies the number of seconds after the reception of the Expect-CT 
header field during which the UA SHOULD regard the host from whom the message was received 
as a Known Expect-CT Host. 


If a response contains an Expect-CT header field, then the response MUST contain an Expect-CT 
header field with a max-age directive. (A max-age directive need not appear in every Expect-CT 
header field in the response.) The max-age directive is REQUIRED to have a directive value, for 
which the syntax (after quoted-string unescaping, if necessary) is defined in Figure 3. 
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delta-seconds 
1*DIGIT 


max-age-value 
delta-seconds 


Figure 3: Syntax of the max-age Directive Value 
delta-seconds is used as defined in Section 1.3 of [RFC9111]. 


2.1.4. Examples 


The following three examples demonstrate valid Expect-CT response header fields (where the 
second splits the directives into two field instances): 


Expect-CT: max-age=86400, enforce 


Expect-CT: max-age=86400, enforce 
Expect-CT: report-uri="https://foo.example/report" 


Expect-CT: max-age=86400, report-uri="https://foo.example/report" 


Figure 4: Examples of Valid Expect-CT ResponseHeader Fields 


2.2. Host Processing Model 


This section describes the processing model that Expect-CT Hosts implement. The model has 2 
parts: (1) the processing rules for HTTP request messages received over a secure transport (e.g., 
authenticated, non-anonymous TLS); and (2) the processing rules for HTTP request messages 
received over non-secure transports, such as TCP. 


2.2.1. HTTP-over-Secure-Transport Request Type 


An Expect-CT Host includes an Expect-CT header field in its response. The header field MUST 
satisfy the grammar specified in Section 2.1. 


Establishing a given host as an Expect-CT Host, in the context of a given UA, is accomplished as 
follows: 


1. Over the HTTP protocol running over secure transport, by correctly returning (per this 
specification) a valid Expect-CT header field to the UA. 


2. Through other mechanisms such as a client-side preloaded Expect-CT Host list. 


2.2.2. HTTP Request Type 


Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP responses conveyed 
over non-secure transport. 


2.3. User Agent Processing Model 


The UA processing model relies on parsing domain names. Note that internationalized domain 
names SHALL be canonicalized by the UA according to the scheme in Section 10 of [RFC6797]. 
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The UA stores Known Expect-CT Hosts and their associated Expect-CT directives. This data is 
collectively known as a host's "Expect-CT metadata". 


2.3.1. Missing or Malformed Expect-CT Header Fields 


If an HTTP response does not include an Expect-CT header field that conforms to the grammar 
specified in Section 2.1, then the UA MUST NOT update any Expect-CT metadata. 


2.3.2. Expect-CT Header Field Processing 


If the UA receives an HTTP response over a secure transport that includes an Expect-CT header 
field conforming to the grammar specified in Section 2.1, the UA MUST evaluate the connection on 
which the header field was received for compliance with the UA's CT Policy, and then process the 
Expect-CT header field as follows. UAs MUST ignore any Expect-CT header field received in an 
HTTP response conveyed over non-secure transport. 


If the connection does not comply with the UA's CT Policy (i.e., the connection is not CT qualified), 
then the UA MUST NOT update any Expect-CT metadata. If the header field includes a report-uri 
directive, the UA SHOULD send a report to the specified report-uri (Section 2.3.3). 


If the connection complies with the UA's CT Policy (i.e., the connection is CT qualified), then the UA 
MUST either: 


e Note the host as a Known Expect-CT Host if it is not already so noted (see Section 2.3.2.1) or 


e Update the UA's cached information for the Known Expect-CT Host if the enforce, max-age, 
or report-uri header field value directives convey information different from that already 
maintained by the UA. If the max-age directive has a value of 0, the UA MUST remove its 
cached Expect-CT information if the host was previously noted as a Known Expect-CT Host 
and MUST NOT note this host as a Known Expect-CT Host if it is not already noted. 


If a UA receives an Expect-CT header field over a CT-compliant connection that uses a version of 
Certificate Transparency other than [RFC6962] or [RFC9162], the UA MUST ignore the Expect-CT 
header field and clear any Expect-CT metadata associated with the host. 


2.3.2.1. Noting Expect-CT 


Upon receipt of the Expect-CT response header field over an error-free TLS connection (with X.509 
certificate chain validation as described in [RFC5280], as well as the validation described in 
Section 2.4 of this document), the UA MUST note the host as a Known Expect-CT Host, storing the 
host's domain name and its associated Expect-CT directives in non-volatile storage. 


To note a host as a Known Expect-CT Host, the UA MUST set its Expect-CT metadata in its Known 
Expect-CT Host cache (as specified in Section 2.3.2.2), using the metadata given in the most 
recently received valid Expect-CT header field. 


For forward compatibility, the UA MUST ignore any unrecognized Expect-CT header field 
directives while still processing those directives it does recognize. Section 2.1 specifies the 
directives enforce, max-age, and report-uri, but future specifications and implementations 
might use additional directives. 
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2.3.2.2. Storage Model 


If the substring matching the host production from the Request-URI (of the message to which the 
host responded) does not exactly match an existing Known Expect-CT Host's domain name, per 
the matching procedure for a Congruent Match specified in Section 8.2 of [RFC6797], then the UA 
MUST add this host to the Known Expect-CT Host cache. The UA caches: 


e the Expect-CT Host's domain name. 
e whether the enforce directive is present. 


e the Effective Expiration Date, which is the Effective Expect-CT Date plus the value of the max- 
age directive. Alternatively, the UA MAY cache enough information to calculate the Effective 
Expiration Date. The Effective Expiration Date is calculated from when the UA observed the 
Expect-CT header field and is independent of when the response was generated. 


e the value of the report-uri directive, if present. 


If any other metadata from optional or future Expect-CT header directives are present in the 
Expect-CT header field, and the UA understands them, the UA MAY note them as well. 


UAs MAY set an upper limit on the value of max-age so that UAs that have noted erroneous 
Expect-CT Hosts (whether by accident or due to attack) have some chance of recovering over 
time. If the server sets a max-age greater than the UA's upper limit, the UA may behave as if the 
server set the max-age to the UA's upper limit. For example, if the UA caps max-age at 5,184,000 
seconds (60 days), and an Expect-CT Host sets a max-age directive of 90 days in its Expect-CT 
header field, the UA may behave as if the max- age were effectively 60 days. (One way to achieve 
this behavior is for the UA to simply store a value of 60 days instead of the 90-day value provided 
by the Expect-CT Host.) 


2.3.3. Reporting 


If the UA receives, over a secure transport, an HTTP response that includes an Expect-CT header 
field with a report-uri directive, and the connection does not comply with the UA's CT Policy 
(i.e., the connection is not CT qualified), and the UA has not already sent an Expect-CT report for 
this connection, then the UA SHOULD send a report to the specified report-uri as specified in 
Section 3. 


2.4. Evaluating Expect-CT Connections for CT Compliance 


When a UAsets up a TLS connection, the UA determines whether the host is a Known Expect-CT 
Host according to its Known Expect-CT Host cache. An Expect-CT Host is "expired" if the Effective 
Expiration Date refers to a date in the past. The UA MUST ignore any expired Expect-CT Hosts in its 
cache and not treat such hosts as Known Expect-CT Hosts. 


When a UA connects to a Known Expect-CT Host using a TLS connection, if the TLS connection 
has no errors, then the UA will apply an additional correctness check: compliance with a CT 
Policy. A UA should evaluate compliance with its CT Policy whenever connecting to a Known 
Expect-CT Host. However, the check can be skipped for local policy reasons (as discussed in 
Section 2.4.1) or in the event that other checks cause the UA to terminate the connection before CT 
compliance is evaluated. For example, a Public Key Pinning failure [RFC7469] could cause the UA 
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to terminate the connection before CT compliance is checked. Similarly, if the UA terminates the 
connection due to an Expect-CT failure, this could cause the UA to skip subsequent correctness 
checks. When the CT compliance check is skipped or bypassed, Expect-CT reports (Section 3) will 
not be sent. 


When CT compliance is evaluated for a Known Expect-CT Host, the UA MUST evaluate compliance 
when setting up the TLS session, before beginning an HTTP conversation over the TLS channel. 


If a connection to a Known Expect-CT Host violates the UA's CT Policy (i.e., the connection is not 
CT qualified), and if the Known Expect-CT Host's Expect-CT metadata indicates an enforce 
configuration, the UA MUST treat the CT compliance failure as an error. The UA MAY allow the user 
to bypass the error unless connection errors should have no user recourse due to other policies in 
effect (such as HSTS, as described in Section 12.1 of [RFC6797]). 


If a connection to a Known Expect-CT Host violates the UA's CT Policy, and if the Known Expect-CT 
Host's Expect-CT metadata includes a report-uri, the UASHOULD send an Expect-CT report to 
that report-uri (Section 3). 


2.4.1. Skipping CT Compliance Checks 


It is acceptable for a UAto skip CT compliance checks for some hosts according to local policy. For 
example, a UA MAY disable CT compliance checks for hosts whose validated certificate chain 
terminates at a user-defined trust anchor rather than a trust anchor built in to the UA (or 
underlying platform). 


If the UA does not evaluate CT compliance, e.g., because the user has elected to disable it, or 
because a presented certificate chain chains up to a user-defined trust anchor, UAs SHOULD NOT 
send Expect-CT reports. 


3. Reporting Expect-CT Failure 


When the UA attempts to connect to a Known Expect-CT Host and the connection is not CT 
qualified, the UA SHOULD report Expect-CT failures to the report-uri, if any, in the Known 
Expect-CT Host's Expect-CT metadata. 


When the UA receives an Expect-CT response header field over a connection that is not CT 
qualified, if the UA has not already sent an Expect-CT report for this connection, then the UA 
SHOULD report Expect-CT failures to the configured report-uri, if any. 


3.1. Generating a Violation Report 


To generate a violation report object, the UA constructs a JSON [RFC8259] object with the 
following keys and values: 
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"date-time" 


The value for this key indicates the UTC time that the UA observed the CT compliance failure. 


The value is a string formatted according to Section 5.6 of [RFC3339], "Internet Date/Time 
Format”. 


"hostname" 


The value is the hostname to which the UA made the original request that failed the CT 
compliance check. The value is provided as a string. 


port" 


The value is the port to which the UA made the original request that failed the CT compliance 
check. The value is provided as an integer. 


"scheme" 


(optional) The value is the scheme with which the UA made the original request that failed the 


CT compliance check. The value is provided as a string. This key is optional and is assumed to 
be "https" if not present. 


"effective-expiration-date" 


The value indicates the Effective Expiration Date (see Section 2.3.2.2) for the Expect-CT Host 
that failed the CT compliance check, in UTC. The value is provided as a string formatted 
according to Section 5.6 of [RFC3339], "Internet Date/Time Format". 


"served-certificate-chain" 


The value is the certificate chain as served by the Expect-CT Host during TLS session setup. The 
value is provided as an array of strings, which MUST appear in the order that the certificates 


were served; each string in the array is the Privacy-Enhanced Mail (PEM) representation of 
each X.509 certificate as described in [RFC7468]. 


"validated-certificate-chain" 


The value is the certificate chain as constructed by the UA during certificate chain verification. 
(This may differ from the value of the "served-certificate-chain" key.) The value is provided as 
an array of strings, which MUST appear in the order matching the chain that the UA validated; 
each string in the array is the PEM representation of each X.509 certificate as described in 
[RFC7468]. The first certificate in the chain represents the end-entity certificate being verified. 


UAs that build certificate chains in more than one way during the validation process SHOULD 
send the last chain built. 


"scts" 


The value represents the SCTs (if any) that the UA received for the Expect-CT Host and their 
validation statuses. The value is provided as an array of JSON objects. The SCTs may appear in 
any order. Each JSON object in the array has the following keys: 


e A "version" key, with an integer value. The UA MUST set this value to 1 if the SCT is in the 


format defined in Section 3.2 of [RFC6962] or 2 if it is in the format defined in Section 4.5 of 
[RFC9162]. 


e The "status" key, with a string value that the UA MUST set to one of the following values: 
"unknown" (indicating that the UA does not have or does not trust the public key of the log 
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from which the SCT was issued); "valid" (indicating that the UA successfully validated the 
SCT as described in Section 5.2 of [RFC6962] or Section 8.1.3 of [RFC9162]); or "invalid" 
(indicating that the SCT validation failed because of a bad signature or an invalid 
timestamp). 

e The "source" key, with a string value that indicates from where the UA obtained the SCT, as 
defined in Section 3 of [RFC6962] and Section 6 of [RFC9162]. The UA MUST set the value to 
one of the following: "tls-extension", "ocsp", or "embedded". These correspond to the three 
methods of delivering SCTs in the TLS handshake that are described in Section 3.3 of 
[RFC6962]. 

e The "serialized_sct" key, with a string value. If the value of the "version" key is 1, the UA 
MUST set this value to the base64-encoded [RFC4648] serialized 
SignedCertificateTimestamp structure from Section 3.2 of [RFC6962]. The base64 
encoding is defined in Section 4 of [RFC4648]. If the value of the "version" key is 2, the UA 
MUST set this value to the base64-encoded [RFC4648] serialized TransItem structure 
representing the SCT, as defined in Section 4.5 of [RFC9162]. 


"failure-mode" 
The value indicates whether the Expect-CT report was triggered by an Expect-CT policy in 
enforce or report-only mode. The value is provided as a string. The UA MUST set this value to 
"enforce" if the Expect-CT metadata indicates an enforce configuration, and "report-only" 
otherwise. 


"test-report" 
(optional) The value is set to true if the report is being sent by a testing client to verify that the 
report server behaves correctly. The value is provided as a boolean and MUST be set to true if 
the report serves to test the server's behavior and can be discarded. 


3.2. Sending a Violation Report 


The UA SHOULD report Expect-CT failures for Known Expect-CT Hosts: that is, when a connection 
to a Known Expect-CT Host does not comply with the UA's CT Policy and the host's Expect-CT 
metadata contains a report-uri. 


Additionally, the UA SHOULD report Expect-CT failures for hosts for which it does not have any 
stored Expect-CT metadata; that is, when the UA connects to a host and receives an Expect-CT 
header field that contains the report-uri directive, the UA SHOULD report an Expect-CT failure if 
the connection does not comply with the UA's CT Policy. 


The steps to report an Expect-CT failure are as follows. 


1. Prepare a JSON object report object withthe single key "expect-ct-report", whose value is 
the result of generating a violation report object as described in Section 3.1. 


2.Let report body be the JSON stringification of report object. 
3. Let report-uri be the value of the report-uri directive in the Expect-CT header field. 


4. Send an HTTP POST request to report-uri witha Content-Type header field of 
application/expect-ct-report+json and an entity body consisting of report body. 
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The UA MAY perform other operations as part of sending the HTTP POST request, such as sending 
a Cross-Origin Resource Sharing (CORS) preflight as part of [FETCH]. 


Future versions of this specification may need to modify or extend the Expect-CT report format. 
They may do so by defining a new top-level key to contain the report, replacing the "expect-ct- 
report" key. Section 3.3 defines how report servers should handle report formats that they do not 
support. 


3.3. Receiving a Violation Report 


Upon receiving an Expect-CT violation report, the report server MUST respond with a 2xx 
(Successful) status code if it can parse the request body as valid JSON, the report conforms to the 
format described in Section 3.1, and it recognizes the scheme, hostname, and port in the "scheme", 
"hostname", and "port" fields of the report. If the report body cannot be parsed or does not 
conform to the format described in Section 3.1, or the report server does not expect to receive 
reports for the scheme, hostname, or port in the report, then the report server MUST respond with 
a 400 Bad Request status code. 


As described in Section 3.2, future versions of this specification may define new report formats 
that are sent witha different top-level key. If the report server does not recognize the report 
format, the report server MUST respond with a 501 Not Implemented status code. 


If the report's "test-report" key is set to true, the server MAY discard the report without further 
processing but MUST still return a 2xx (Successful) status code. If the "test-report" key is absent or 
set to false, the server SHOULD store the report for processing and analysis by the owner of the 
Expect-CT Host. 


4. Usability Considerations 


When the UA detects a Known Expect-CT Host in violation of the UA's CT Policy, end users will 
experience denials of service. It is advisable for UAs to explain to users why they cannot access 
the Expect-CT Host, e.g., in a user interface that explains that the host's certificate cannot be 
validated. 


5. Authoring Considerations 


Expect-CT could be specified as a TLS extension or X.509 certificate extension instead of an HTTP 
response header field. Using an HTTP header field as the mechanism for Expect-CT introduces a 
layering mismatch; for example, the software that terminates TLS and validates Certificate 
Transparency information might know nothing about HTTP. Nevertheless, an HTTP header field 
was chosen primarily for ease of deployment. In practice, deploying new certificate extensions 
requires certificate authorities to support them, and new TLS extensions require server software 
updates, including possibly to servers outside of the site owner's direct control (such as in the case 
of a third-party Content Delivery Network (CDN)). Ease of deployment is a high priority for 
Expect-CT because it is intended as a temporary transition mechanism for user agents that are 
transitioning to universal Certificate Transparency requirements. 
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6. Privacy Considerations 


Expect-CT can be used to infer what Certificate Transparency Policy a UA is using by attempting 
to retrieve specially configured websites that pass one user agent's policies but not another's. 
Note that this consideration is true of UAs that enforce CT policies without Expect-CT as well. 


Additionally, reports submitted to the report-uri could reveal information to a third party 
about which web page is being accessed and by which IP address, by using individual report-uri 
values for individually tracked pages. This information could be leaked even if client-side 
scripting were disabled. 


Implementations store state about Known Expect-CT Hosts and, hence, which domains the UA 
has contacted. Implementations may choose to not store this state subject to local policy (e.g., in 
the private browsing mode of a web browser). 


Violation reports, as noted in Section 3, contain information about the certificate chain that has 
violated the CT Policy. In some cases, such as an organization-wide compromise of the end-to-end 
security of TLS, this may include information about the interception tools and design used by the 
organization that the organization would otherwise prefer not be disclosed. 


Because Expect-CT causes remotely detectable behavior, it's advisable that UAs offer a way for 
privacy-sensitive end users to clear currently noted Expect-CT Hosts and allow users to query the 
current state of Known Expect-CT Hosts. 


7. Security Considerations 


7.1. Hostile Header Attacks 


When UAs support the Expect-CT header field, it becomes a potential vector for hostile header 
attacks against site owners. If a site owner uses a certificate issued by a certificate authority that 
does not embed SCTs nor serve SCTs via the Online Certificate Status Protocol (OCSP) or TLS 
extension, a malicious server operator or attacker could temporarily reconfigure the host to 
comply with the UA's CT Policy and add the Expect-CT header field in enforcing mode witha long 
max-age. Implementing user agents would note this as an Expect-CT Host (see Section 2.3.2.1). 
After having done this, the configuration could then be reverted to not comply with the CT Policy, 
prompting failures. Note that this scenario would require the attacker to have substantial control 
over the infrastructure in question, being able to obtain different certificates, change server 
software, or act as a man in the middle in connections. 


Site operators can mitigate this situation by one of the following: reconfiguring their web server 
to transmit SCTs using the TLS extension defined in Section 6.5 of [RFC9162]; obtaining a 
certificate from an alternative certificate authority that provides SCTs by one of the other 
methods; or by waiting for the user agent's persisted notation of this as an Expect-CT Host to 
reach its max- age. User agents may choose to implement mechanisms for users to cure this 
situation, as noted in Section 4. 
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7.2. Maximum max-age 


There is a security trade-off in that low maximum values provide a narrow window of protection 
for users that visit the Known Expect-CT Host only infrequently, while high maximum values 
might result in a denial of service to a UA in the event of a hostile header attack or simply an 
error on the part of the site owner. 


There is probably no ideal maximum for the max-age directive. Since Expect-CT is primarily a 
policy-expansion and investigation technology rather than an end-user protection, a value on 
the order of 30 days (2,592,000 seconds) may be considered a balance between these competing 
security concerns. 


7.3. Amplification Attacks 


Another kind of hostile header attack uses the report-uri mechanism on many hosts not 
currently exposing SCTs as a method to cause a denial of service to the host receiving the reports. 
If some highly trafficked websites emitted a non-enforcing Expect-CT header field witha report- 
uri, implementing UAs' reports could flood the reporting host. It is noted in Section 2.1.1 that UAs 
should limit the rate at which they emit reports, but an attacker may alter the Expect-CT header 
fields to induce UAs to submit different reports to different URIs to still cause the same effect. 


8. IANA Considerations 


8.1. Header Field Registry 


This document registers the "Expect-CT" header field in the "Hypertext Transfer Protocol (HTTP) 
Field Name Registry" registry located at <https://www.iana.org/assignments/http-fields>. 


Header field name: Expect-CT 

Applicable protocol: http 

Status: permanent 

Author/Change controller: IETF 
Specification document(s): This document 


Relatedinformation: (empty) 


8.2. Media Types Registry 


This document registers the application/expect-ct-report+json media type (which uses the 
suffix established in [RFC6839]) for Expect-CT violation reports in the "Media Types" registry as 
follows. 
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Typename: application 

Subtype name: expect-ct-report+json 
Required parameters: n/a 

Optional parameters: n/a 

Encoding considerations: binary 
Security considerations: See Section 7 
Interoperability considerations: n/a 
Published specification: This document 


Applications that use this media type: UAs that implement Certificate Transparency compliance 
checks and reporting 


Additional information: 
Deprecated alias names for this type: n/a 
Magic number(s): n/a 
File extension(s): n/a 
Macintosh file type code(s): n/a 


Person & email address to contact for further information: 
Emily Stark (estarkK@google.com) 


Intended usage: COMMON 
Restrictions on usage: none 
Author: Emily Stark (estark@google.com) 


Change controller: IETF 
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